モルガン・スタンレー社の HPC 活用事例から学ぶストレージ選択、EC2 の購入オプション

大村保貴

2022.09.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

モルガン・スタンレー社のリスクカリキュレーション用途での HPC 活用事例から AWS ParallelCluster, AWS Batch にでも適用できる Tips をまとめました。

AWS re:Invent 2021 で登壇されていた動画から気になったピックアップしています。AWS ParallelCluster, AWS Batch の AWS で提供されている HPC サービスを利用せずに独自にクラスターを構築されておりますので、EC2 駆使して独自にクラスターを組みたい方は一度通してご確認されるとよろしいかと思います。

Morgan Stanley's evolution of HPC grid on AWS

IBM Spectrum Symphony を用いた独自のHPC環境（グリッドコンピューティング）を構築されています。Symphony Manager が ParallelCluster でいうところのヘッドノードに相当する機能を有したインスタンスの様です。コンピュートノードは EC2 ですが、計算処理の実行は Docker を利用されており、Docker on ParallelClusterのイメージにほど近い印象です。

独自のクラスター環境のため、紹介されているすべてのナレッジを私がよく利用する ParallelClusterや、AWS Batch に適用はできませんでした。それでも有益な情報があり、後に振り返って動画を確認するのは手間のため必要な内容をまとめます。

EFS と FSｘ for Lustre の選択

Morgan Stanley の Executive Directore を務める Vikas Chawla さんにとっては FSx for Lustre は強化された EFS という認識。理由は双方ともに POSIX サポートしているため。

FSx for Lustre を選択するケース
- 1,000,000 IOPS または数10GB/秒の読み書きある場合
EFS を選択するケース
- 500,000 IOPS 以下の場合

AZ 選択

EFS と Lustre では Lustre はひとつの AZ にしかエンドポイントを作成できない違いがある。

エンドポイントと異なる AZ にコンピュートリソースを作成した場合、クロス AZ の通信料が発生する。

改めて調べてみた

クロス AZ のデータ転送料金: $0.01/GB（in/out）

Data transferred "in" to and "out" from Amazon EC2, Amazon RDS, Amazon Redshift, Amazon DynamoDB Accelerator (DAX), and Amazon ElastiCache instances, Elastic Network Interfaces or VPC Peering connections across Availability Zones in the same AWS Region is charged at $0.01/GB in each direction.

EC2 On-Demand Instance Pricing – Amazon Web Services

クロス AZ 通信のデータ転送は構成図があると理解しやすいので以下のIngress/Egress Date Transfer Chargeの箇所を参考にしてください。

画像引用: Overview of Data Transfer Costs for Common Architectures | AWS Architecture Blog

データ転送時の暗号化

EFS はマウントヘルパーを介したデータ暗号化をサポートしているが Lustre ではできない。なので、VPC Encryption を使用するが、サポートしているインスタンスタイプ（m6i など）は限定的です。

セキュリティ対策はしっかりされているため、データ転送経路上の暗号化や、暗号化も CMK されていました。

改めて調べてみた

現時点では2021年4月11日以降に作成した Lustre はデータ転送時の暗号化をサポートしているため、導入当時に感じたデメリットは解消されている様子です。

EFS パフォーマンスモード

高負荷なワークロード、高い IOPSが必要でした。
- 500,000 IOPS に近く 300,000 IOPS を超えていたので Max I/O モードを選択した。

特定のユースケースではレイテンシーが遅く問題となった。Gnerral Purpose に切り替えると問題なくなった。だけど、General Purpose には 35,000 IOPS の制限があります。

常に安定したスループットが求められるワークロードなのでプロビジョンドスループットを採用
クライアントでのファイルキャッシュは Ehcache を利用
デフォルトのマウントオプションは Amazon 推奨値
ひとつのディレクトリには10,000未満のファイル数に保つ（経験上）

改めて調べてみた

General Purpose モードでの 35,000 IOPS 上限は今も変わりありません。多くのケースでは General Purpose モードが推奨されています。

We recommend using General Purpose performance mode for the vast majority of applications.

Amazon EFS performance - Amazon Elastic File System

35,000 IOPS を求められてかつ、EFS である場合に Max I/O モードで解消される問題なのかは検証が必要ですね。

EC2 オプション選択

RI（Reserved Instance）
- 18時間/日以上で週7日継続して実行されるワークロードパターン
オンデマンド
- 18時間/日以下のワークロードパターン
- 一時的に大量の計算リソースが必要かつ、スポットインスタンスの中断を許容できない場合
オンデマンドキャパティ予約
- 計算リソースが必要になることが事前にわかっており、計算処理の開始がスケージュールされているようなケース
- スポットインスタンスの中断を許容できないかつ、RI購入することが理想的ではない場合に費用対効果が高くなる可能性あり
スポットインスタンス
- 最安価なオプション
- 計算リソースは1日複数回スケールアップ・ダウンし、タスクサイズは小さく、タスクを再実行する余裕があるワークロード
- ※ ここでのタスクは Symphony がジョブを複数のタスクに分割して計算リソースに割り振ったものを指しており、ジョブが細分化されたものだと思われます。

Symphony Manager のインスタンスに RI を利用されているとのことでした。ParallelCluster に例えるならヘッドノードが常時起動しているから RI を購入する状況ですね。ただ、ParallelCluster 冗長性は皆無なため、安定の常時起動を求めるときは独自の実装が必要になってきます。

ParallelCluster 2系の時代になりますが、フェイルオーバー構成はウェザーニュース様の事例を参考にしてください。

学んだ重要な教訓

誰も確認しないログを永遠に取り続けていませんか？
EC2 のログと、アプリケーションログをオンプレミスへ戻す必要があるのか自問した
- トラブルシューティングで必要な場合は、AWS に保管して保持期限で管理した方が良いのではないか
なんでもかんでもオンプレミスにデータを引き戻すと多額のデータ転送料になる
データと EC2 は同じ AZ に配置する
- クロス AZ のデータ通信料を回避しながら、最適なパフォーマンスを発揮
- ※ データは EFS や、FSx for Lustre などのストレージサービスのエンドポイントのことを指していると思われる